…rface schema v0.1

dspack v0.3 makes a subset of a design system's institutional knowledge
machine-checkable. Strictly additive over v0.2: a valid v0.2 document with
"dspack": "0.3" validates against the v0.3 schema.

- schema/dspack.v0.3.schema.json: v0.2 + three optional top-level blocks.
  Rules are typed structured predicates (component-choice,
  required-composition, forbidden-composition) — no expression language;
  unknown rule types are schema-invalid per version and must fail loudly
  in linters. Severity is RFC 2119 (must|should); tools map must→error,
  should→warn.
- schema/dspack.surface.v0_1.schema.json: the dspack surface — a
  protocol-neutral component tree in contract vocabulary, the evaluation
  target for rules (gates S1/S2/S3) and the payload of examples[].surface.
  An intermediate representation: never rendered, never transported,
  always compiled.
- spec/dspack-v0.3.md: delta spec with normative per-type evaluation
  semantics, the severity mapping, gate definitions, the three-layer
  formulation, and the deliberate expressiveness ceiling.
- spec/migration-v0.2-to-v0.3.md: guarantees + worked anti-pattern→rule
  conversion.
- examples/shadcn-ui.dspack.json: upgraded to v0.3 with the
  destructive-action intent, three worked rules shadowing existing
  anti-patterns/constraints, and a compilable delete-account example.
- scripts/validate.mjs + fixtures/negative/ + CI: schemas compile; examples
  validate (incl. S1/S2 over example surfaces, cross-reference consistency,
  and the stripped-document back-compat guarantee); ten negative fixtures
  must each be rejected.

Verify: npm ci && npm run validate && npm run validate -- --fixtures negative

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…interactive-descendants

Design grounds, independent of any demo: ADR-7's repair template is designed
to carry a linked example as a corrected reference; the other two rules link
one; a rule whose repair feedback cannot include its corrected reference is
a contract gap regardless of any demo. Deliberately NOT a new example — the
existing one is already in the destructive-action few-shot, so this edit
changes repair feedback only (generation context is byte-identical), making
the rerun a clean A/B on that single variable. A new example would enter
generation context and could suppress first-attempt violations — the line
between fixing the contract and rigging the demo.

Observed consequence (recorded at exactly this strength, evidence in
dspack-gen docs/evidence/2026-07-02-flagship-candidates/): across 11
pipeline runs, rules with a linked example repaired whenever they fired;
the unlinked rule never repaired.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

… sub-component ids

Review fixes (Copilot on #9):
- Closed governance objects (intentEntry, exampleEntry, appliesTo, and the
  nested rule requirement/constraint objects) now carry
  patternProperties ^x-, so x-prefixed extension keys validate per the
  global v0.2 extensibility rule while non-x unknown keys stay rejected.
  Spec delta states the compliance explicitly.
- buildVocabulary() surfaces duplicate sub-component ids and
  checkGovernance() rejects them before any id-dependent check — S2 and
  rule resolution must never depend on object iteration order. Spec delta
  makes document-wide sub-component id uniqueness normative for contracts
  using governance blocks; new negative fixture covers it (11 total).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…e non-x rejection

- checkGovernance() returns early for v0.3 documents that use none of
  intents/rules/examples — the duplicate-sub-id rule is scoped exactly as
  spec §5 states it, preserving the strictly-additive guarantee for pure
  v0.2-shaped documents.
- fixtures/negative/intent-non-x-unknown-key.dspack.json: holds the other
  direction of the extensibility fix in CI — x-owner passes, unknownField
  is rejected (12 negative fixtures total).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>